AMENDMENTfS) TO THE CLAIMS 



1. (currently amended) A method for designing an application 
programming interface (API), the method comprising: 

preparing a plurality of code samples for a core scenario, each respective 
code sample of the plurality of code samples corresponding to a respective 
programming language of a plurality of programming languages;-and 

deriving the API from the core scenario responsive to the plurality of code 
samples ; and 

realizing the derived API in one or more processor-accessible storage 

media . 

2. (currently amended) The method as recited in claim 1, further 
comprising: 

determining, by an API designer, if the derived API is tee- more complex 
than desired . 

3. (currently amended) The method as recited in claim 2, further 
comprising: 

if the derived API is determined to be tee- more complex than desired , then 
refining, by the API designer, the derived API to produce a refined 

API. 
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4. (currently amended) The method as recited in claim 3, further 
comprising: 

determining, by the API designer, if the refined API is tee- more complex 
than desired . 

5. (original) The method as recited in claim 1, further comprising: 
performing one or more usability studies on the API utilizing a plurality of 

developers. 

6. (currently amended) The method as recited in claim 5, wherein the 
performing comprises: 

perforating the one or more usability studies on the API utilizing the 
plurality of developers wherein the plurality of developers are typical for 
com petent with the plurality of programming languages. 

7. (currently amended) The method as recited in claim 5, further 
comprising: 

ascertaining whether the plurality of developers are able to use the API 
without significant p roblems. 

8. (currently amended) The method as recited in claim 7, further 
comprising: 

if the plurality of developers are not ascertained to be able to use the API 
without significant -problems, then revising the API. 
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9. (original) The method as recited in claim 8, wherein the revising 
comprises: 

revising the API based on at least one lesson from the one or more 
usability studies. 

10. (original) The method as recited in claim 1, wherein the deriving 
comprises: 

deriving the API to support the plurality of code samples that 
correspond respectively to the plurality of programming languages. 

11. (original) The method as recited in claim 1, wherein the deriving 
comprises: 

gleaning language-specific mandates from the plurality of code 
samples; and 

incorporating the language-specific mandates into the API. 

12. (original) The method as recited in claim 1, wherein the deriving 
comprises: 

gleaning language-inspired developer expectations from the plurality 
of code samples; and 

incorporating the language-inspired developer expectations into the 

API. 
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13. (original) The method as recited in claim 1, wherein the deriving 
comprises: 

gleaning commonalities from the plurality of code samples; and 
incorporating the commonalities into the API. 

14. (original) The method as recited in claim 1, wherein the deriving 
comprises: 

deriving the API to have an aggregate component that ties a plurality 
of lower-level factored types together to support the core scenario. 

15. (currently amended) A method for designing an application 
programming interface (API), the method comprising: 

selecting a core scenario for a feature area; 
writing at least one code sample for the core scenario;-and 
deriving an API for the core scenario responsive to the at least one code 
sample; and 

realizing the derived API in one or more processor-accessible storage 

media . 

16. (original) The method as recited in claim 15, wherein the selecting 
comprises: 

selecting a plurality of core scenarios for the feature area. 
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17. (original) The method as recited in claim 16, further comprising: 
repeating the writing and the deriving for each core scenario of the plurality 

of core scenarios that are selected for the feature area. 

18. (original) The method as recited in claim 15, wherein the writing 
comprises: 

writing a plurality of code samples for the core scenario, each 
respective code sample of the plurality of code samples corresponding to a 
respective programming language of a plurality of programming languages. 

19. (original) The method as recited in claim 1 8, wherein the deriving 
comprises: 

deriving the API for the core scenario responsive to the plurality of 
code samples. 

20. (currently amended) The method as recited in claim 15, further 
comprising: 

performing one or more usability studies on the API utilizing a plurality of 
developers; 

ascertaining whether the plurality of developers are able to use the API 
without significant problems; and 

if the plurality of developers are not ascertained to be able to use the API 
without significant p roblems, then revising the APT 
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21. (original) The method as recited in claim 20, wherein the revising 
comprises: 

revising the API based on at least one lesson from the one or more 
usability studies to produce a revised API. 

22. (original) The method as recited in claim 2 1 , further comprising: 
repeating the performing and the ascertaining with respect to the revised 

API. 

23. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

deriving the API to support the at least one code sample written for 
the core scenario by producing a two-layer API that includes an aggregate 
component and a plurality of underlying factored types. 

24. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

gleaning one or more language-specific mandates from the at least 
one code sample; and 

incorporating the one or more language-specific mandates into the 

API. 
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25. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

encapsulating a particular factored type into an aggregate component 
that is associated with the core scenario if all members of the particular 
factored type are exposed by the aggregate component. 

26. (currently amended) The method as recited in claim 1 5, wherein the 
deriving comprises: 

encapsulating a particular factored type into an aggregate component 
that is associated with the core scenario if the particular factored type is 
independently uninteresting unrelated t o other component types. 

27. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

exposing a particular factored type from an aggregate component 
that is associated with the core scenario if at least one member of the 
particular factored type is not exposed by the aggregate component. 

28. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

exposing a particular factored type from an aggregate component 
that is associated with the core scenario if the particular factored type can 
be beneficially used independently of the aggregate component by another 
component type. 
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29. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

producing a two-layer framework that includes component types 
targeting a relatively higher level of abstraction and component types 
targeting a relatively lower level of abstraction. 

30. (original) The method as recited in claim 29, wherein the component 
types targeting the relatively higher level of abstraction are directed to core 
scenarios. 

31. (original) The method as recited in claim 29, wherein the component 
types targeting the relatively lower level of abstraction provide a relatively greater 
amount of control to developers as compared to the component types targeting the 
relatively higher level of abstraction. 

32. (original) The method as recited in claim 15, wherein the deriving 
comprises: 

deriving the API so as to enable a developer to implement a create- 
set-call usage pattern for the core scenario. 

33. (original) The method as recited in claim 32, wherein the deriving 
comprises: 

producing the API with pre-selected parameters that are 
appropriate for the core scenario. 
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34. (original) A method for designing an application programming 
interface (API), the method comprising: 

deriving an API for a scenario responsive to at least one code sample 
written with regard to the scenario; 

performing one or more usability studies on the API utilizing a plurality of 
developers; and 

revising the API based on the one or more usability studies. 

35. (original) The method as recited in claim 34, further comprising: 
writing a plurality of code samples with regard to the scenario, each 

respective code sample of the plurality of code samples corresponding to a 
respective programming language of a plurality of programming languages; 

wherein the deriving comprises: 

deriving the API for the scenario responsive to the plurality of code 

samples. 
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36. (currently amended) The method as recited in claim 34, further 
comprising, prior to the performing one or more usability studies on the API: 

determining, by an API designer, if the derived API is tee -more complex 
than desired ; 

if the derived API is determined to be tee -more complex than desired , then 

refining, by the API designer, the derived API to produce a refined 
API; and 

determining, by the API designer, if the refined API is tee- more 
complex than desired . 

37. (currently amended) The method as recited in claim 34, further 
comprising: 

ascertaining whether the plurality of developers are able to use the API 
without significant problems; and 

when the plurality of developers are not ascertained to be able to use the 
API without significant problems, then implementing the revising; 

wherein the revising comprises: 

revising the API based on at least one lesson from the one or more 

usability studies to produce a revised API. 

38. (original) The method as recited in claim 37, further comprising: 
repeating at least the perfonning and the ascertaining with respect to the 

revised API. 
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39. (currently amended) The method as recited in claim 37, wherein the 
ascertaining comprises: 

ascertaining whether the plurality of developers are able to use the 
API without signifi e ant - p roblems with regard to a desired level of usability 
for at least one targeted developer group, wherein the desired level of 
usability includes considerations with respect to (i) frequent and/or 
extensive reference to detailed API documentation by the plurality of 
developers, (ii) a failure of a majority of the plurality of developers to 
implement the scenario, and (iii) whether the plurality of developers take an 
approach that is significan t ly -different from what is expected by an API 
designer. 

40. (currently amended) The method as recited in claim 34, further 
comprising: 

selecting a plurality of core scenarios for a feature area; and 
repeating the deriving, the performing, and the revising for each core 
scenario of the plurality of core scenarios. 

41. (original) The method as recited in claim 40, wherein the deriving 
comprises: 

producing an aggregate component for each core scenario of the 
plurality of core scenarios. 
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42. (original) The method as recited in claim 34, wherein the deriving 
comprises: 

producing an aggregate component that has a respective relationship 
with each respective factored type of a plurality of factored types. 



43. (original) The method as recited in claim 42, wherein the producing 
comprises: 

producing the aggregate component to support the scenario 
for which the at least one code sample is written. 



44. (original) The method as recited in claim 42, wherein the producing 
comprises: 

producing the aggregate component to have an exposed 
relationship with at least one factored type of the plurality of 
factored types and an encapsulated relationship with at least one 
other factored type of the plurality of factored types. 



45. (original) The method as recited in claim 44, wherein the at least 
one other factored type of the plurality of factored types that has the encapsulated 
relationship with the aggregate component can be handed off by the aggregate 
component for direct interaction with another component type. 

46. (original) The method as recited in claim 42, wherein the plurality of 
factored types are designed using an object-oriented methodology. 
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47. (original) A method for designing an application programming 
interface (API), the method comprising: 

preparing a plurality of code samples for a core scenario, each respective 
code sample of the plurality of code samples corresponding to a respective 
programming language of a plurality of programming languages; 

deriving the API for the core scenario responsive to the plurality of code 
samples; 

perfonning one or more usability studies on the API utilizing a plurality of 
developers; and 

revising the API based on the one or more usability studies. 

48. (currently amended) A method for designing an application 
programming interface (API), the method comprising: 

writing at least one code sample for a scenario;-and 

deriving an API for the scenario responsive to the at least one code sample, 
the API including (i) an aggregate component that is adapted to facilitate 
implementation of the scenario and (ii) a plurality of factored types that provide 
underlying functionality for the aggregate component, the API enabling a gradual 
progression from using the aggregate component in simpler situations to using an 
increasing portion of the plurality of factored types in increasingly complex 
situations ; and 

realizing the derived API in one or more processor-accessible storage 

media . 
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49. (currently amended) A method for designing an application 
programming interface (API), the method comprising: 

deriving at least one aggregate component to support at least one code 
sample for at least one scenario; 

determining additional requirements with respect to the at least one 
scenario; 

deciding if the additional requirements can be added to the at least one 
aggregate component without adding undue -more complexity than desired to the at 
least one scenario;-and 

if it is decided that the additional requirements can n ot be added to the at 
least one aggregate component without adding more complexity than desired to the 
at least one scenario , then: 

defining a plurality of factored types responsive to the deciding; 
realizing the at least one aggregate component in one or more 
processor-accessible storage media; and 

realizing the plurality of factored types in the one or more processor- 
accessible storage media; and 

if it is decided that the additional requirements can be added to the at least 
one aggregate component without adding more complexity than desired to the at 
least one scenario, then: 

refining the at least one aggregate component to incorporate the 
additional requirements; and 

realizing the refined at least one aggregate component in the one or 
more processor-accessible storage media . 
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50. (canceled) 



51. (original) The method as recited in claim 49, further comprising: 
selecting a plurality of core scenarios for a feature area, the plurality of core 

scenarios including the at least one scenario; and 

writing a plurality of code samples showing preferred lines of code for the 
plurality of core scenarios, the plurality of code samples including the at least one 
code sample; 

wherein the deriving comprises: 

deriving a plurality of aggregate components, which include the at 

least one aggregate component, to support the plurality of code samples for 

the plurality of core scenarios. 

52. (currently amended) The method as recited in claim 49, wherein the 
deriving comprises: 

deriving the at least one aggregate component with appropriat e 
methods, defaults, and abstractions to support the at least one code sample 
for the at least one scenario. 



Lie & Hayes, pile 



17 



MSl-!748US.Rep!y,To.NfOA-l IAprf)7 



53. (currently amended) The method as recited in claim 49, further 
comprising: 

refining the at least one code sample according to the at least one derived 
aggregate component;-and 

evaluating the refined at least one code sample with regard to simplicity; 

and 

repeating the deriving if the refined at least one code sample fails to be 
sufficiently as simple as desired as determined in the evaluating. 

54. (original) The method as recited in claim 49, wherein the 
determining comprises: 

determining additional requirements with respect to the at least one 
scenario, wherein the additional requirements include additional scenarios, 
additional usages, and additional interactions with other component types. 

55. (original) The method as recited in claim 49, wherein the deciding 
comprises: 

considering whether adding the additional requirements to the at 
least one aggregate component hinders a create-set-call usage pattern. 

56. (currently amended) The method as recited in claim 49, wherein the 
defining comprises: 

defining the plurality of factored types responsive to the deciding 
with a B~ideal -a_factoring of a full set of functionality. 
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57. (original) The method as recited in claim 49, wherein the defining 
comprises: 

defining the plurality of factored types responsive to the deciding 
using one or more object-oriented methodologies. 

58. (original) The method as recited in claim 49, further comprising: 
determining whether the at least one aggregate component is to encapsulate 

or expose the functionality of each factored type of the plurality of factored types. 

59. (original) The method as recited in claim 49, further comprising: 
refining the plurality of factored types to support the at least one aggregate 

component and the additional requirements. 
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